MASSACHUSETTS INSTITUTE OF TECHNOLOGY 
A. I. LABORATORY 


Artificial Intelligence 

Memo No. 255 February 3* 1972 


WHY CONNIVING IS SETTER THAN PLANNING 
GeraId Jay Sussman 


Work reported herein was conducted, at the Artificial Intelligence Lab¬ 
oratory* a Massachusetts Institute of Technology research program sup¬ 
ported In part by the Advanced Research Projects Agency of the Department 
of Defense and monitored by the Office of Naval Research under Contract 
Number NOQO14-JD-A-Q362-D0Q?. 


Reproduction of this document* In v^hole or in part, is permitted for any 
purpose of the United States Government. 


PAGE 2 


Acknowledgment; 

3 must deeply acknowledge the profound influence of Joel Hoses on 
this paper* Some of the ideas here are directly due to him; others were 
independently arrived at by him* Host of my ideas were arrived at by 
observation of real users of MICRO-PLAMUi as part of my duties in its 
Kaintenance* Drew McDermott* Tom Knight, Terry ftinc^rad, Greenblatt, 

East lake, and Gosper provided valuable sounding boards for these ideas. 




PAGE 3 


The Problem with PLANNER 

A higher level language derives its great power from the fact 
that it tends to impose structure on the problem solving behavior for the 
user. Besides providing a library of useful subroutines with a uniform 
calling sequence, the author of a higher level language imposes his 
theory of problem solving on the user. By choosing what primitive data 
structures, control structures, and operators he presents to the user, he 
calces the implementation of some algorithms more difficult than others, 
thus discouraging some techniques and encouraging others* So, to be 
■'gocd 11 , s. higher level language must not only simplify the job of 
programming, by providing features which package programming structures 
CCmmemly found in the domain for which the language was designed, it must 
also do its best to discourage the use of structures which lead to “bad 11 
algorithus* 

for example, consider the problem of calculating the n th element 
in the Fibonacci sequence* In LISP, the most natural algorithm for this 
computation is the exponentially exploding, doubly recursive: 
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(DERJA Hfl (W) 

(OCND ((ZEROP U) 1) 

((OKEP M) 1) 

(T (+ (FIE (- N 1)) 

(PIE (- U 2)J))}} 

A much better (linear in H rather til an 2#*N) but less natural (in LISP) 
algorithm is: 

(DEFliM TIB (N) 

(CCM>((Z£RQP N) 1) 

(T (FRCG (Ml MM2 THi) 

{SETQ HH1 1} 

(STO 0M£ 1) 

IF (CUND ((CHEF ft) (KETURH Ml))) 

(SETQ TEM (+ Ml HM2)) 

(SETQ m2 JilWI) 

(SETQ NH1 TEH) 

(SETQ N (- N 1)) 

(go mm ) 

Thus LISP has led us down the wrung path* Is LISP a bad language 
because recursion Is easy and automatic? I think cot* The mechanise; of 
recursive control structure f though the wrong one to use in this 
admittedly somewhat pathological case, is often both the acst natural and 
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most efficient control structure* especially in problems of symbolic 
manipulation for which LISP wels designed, 

With this in nine, let us now consider backtrack control 
structure, which occupies a place in PLAUHEft analogous to that of 
recursion in LISP, I contend that automatic backtracking is the wrong 
structure- for the domain for which FLAMNER was intended* that is, 
Artificial Intelligence* I will argue that: 

1, These cases in which automatic hecktrack control is natural 
and appropriate are always the worst algorithms for solving a problem, 

2* The most commonly used case of automatic backtracking can 
almost always be replaced by a purely recursive structure which is not 
only more efficient but also clearer, both semantically and 
syntaCt ically * 

3- The availability of autojiiatic backtracking encourages 

superficial analysis of problems ar.d poor programming practice; much 

worse, the pervasiveness of automatic backtracking in the PLANNQl 
language discourages deep analysis of problems* 

4- Attempts to fix 3 by the introduction of the artifice of 
failure messages are unnatural and cumbersome. 

Thus I contend that the problem with FUd^EF is automatic 
backtrack control structure. I must stress, however, that FLANTIIR has 
introduced aany valuable constructs into our way of thinking, the most 
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important of which are pattern-directed data base search and pattern^ 
directed procedural invocation -which tend to promote easy interfacing 
between programs, a greet boon to our lab. Note that I am also not 
contending that good programs cannot be implemented in PLANNER; that 
would be absurd. I am only claiming that PLANNER does not encourage such 
behavior. 


We now consider the points in detail. 

1. We will readily admit that the "best" programs do no 
backtracking; they know where they are going at each step and never need 
to undo a bad decision. Goad programs that know the structure of the 
problem domain (such, as Moses' SIN) have no need for an ability to thrash 
about, searching for a good approach (as in SAINT). Pure backtracking 
(without failure messages) is essentially a mechanism for easily undoing 
a bad decision in the hope that a better alternative will be found. Thus 
it is only appropriate to algorithms which make such bad decisions either 
because of lack cf sufficient guiding structure in the problem space or 
of sufficient knowledge of that structure in the program. At this point 
you may complain that in most interesting spaces not enough may be known 
about the space a priori to guide & program absolutely; that a good 
program may have td probe the space with experiments which then yield 
information which guides the rest of the program. Indeed, this is true; 
but it is just these cases, in which we want to be able to return not 
only information about why a particular method failed to achieve its 
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stated goal* tint information about the structure of the space: discovered 
along the way, in which we must resort to the highly unsatisfactory 
neehanisiL of failure messages'* 

2, Observation of Pat Winstcan's group's use of WICRC-PIWfNJiiR 

tends to indicate that one of the more important uses of backtracking, in 
programs which are not searching because they know exactly where they are 

going, is in information retrieval- These programs maintain rather 
Eassive data bases of inf creation about a. visual scene* Such program 

often oust be able to search out relevant goodies from a mass of 
irrelevancies. for example; 

(COAX TO IS JBICJ) 

(COAL (?X IS GREEN)) 

(GOAL (?X ON *?Y)) 

(GOAL (7Y IS BLUE)) 

(stuff ?X ?I) 

This means "do the stuff" on objects X and Y such that "the big green X 
is on the blue Y*" Note that what is going on here is sequential 
filtering of the possible assignments of X and Y by pattern directed 
search of the data base and theorems.- Vie see that backtracking is used 
here because any cifoice of a particular big X may he had because that 
particular X may not be green. The stack frame of each goal statement 
thus maintains a list of the hitherto untried possibilities and if a 
failure reaches it, it tries the next one and proceeds down- A much 
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simpler and sore straightforward approach would he to use ordinary 
recursive and iterative control structure to filter the possibilities 
directly. Thus, for example, it is easy to write a LliSP function fOR- 
EACH with which one ptigiit write: 

(OT-EACH (?X IS BIG) 

(EOF;-EACH (?X IS GREEN ) 

(FOR-EACH (?X GW ?Y) 

(IOH—EACH (?Y IS BLUE) 

(stuff 7X ?Y))))) 

(of course a macro could be provided, which expanded f say the following 
into the above) 

(PIKTERS £(?X IS BIG) 

(7X IS CRM) 

(7X ON ?Y) 

(?Y IS BLUE) 

(stuff ?X ?Y]) 

here, EOR-EACH is just a standard LISP function which, upon entry, looks 
up nil of the assertions and theorems Batching the pattern given as Its 
first argument (with values substituted for variables which are 
assigned). It then assumes the first possibility, assigning variables 
appropriately, ar>I evals its second argument. If the expression ever 
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returns, rather than leaving the loop, the list of possibilities is CDRed 
and the process repeats* Notice that by appropriately nesting our loops 

no backtracking is required in the data retrieval* here stuff is done or. 
each X arid Y which satisfies the criteria unless stuff decides it has had 
enough- This good nesting of loops has decided advantages- Besides 
being core efficient than backtracking (a marginal advantage), good, 
nesting Fakes the scope of the action clear* There is no chan ce an 
unexpected failure will propagate hack into this mess and chug along 
without our explicit prograjiiming of a failure catcher* 1 want to 
Cfflphasize that this is not a Bade up problem* I am not sitting on my 
butt contemplating my navel* This problem is observed in real users of 
NICBO-PIANNER who complain that they just can't control their programs 
because they don't know what the programs sgne doing. The problem is 
really quite insidious. Usually any choice made in the offending piece 

of code eventually f^ils for the same reason that the first one did; then 
the only symptom that the program is running amok is that it takes 
forever to tell you it can't win* Let's consider the options aval Table 

to the user to prevent this problem. You might say that he should 
finalize the program from just before the first filter to just after the 
code which he doesn't want reentered upon failure, but this is 
unsatisfactory because the code in question probably has side effects 
which should be undone upon failure from outside the intended code, but 
we want that failure not to be reversed, by this block of code. All in 
all I think that it is essentially clearer if any loops Or lasting 
structure is desired, that it should be made explicit rather than 
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implicit bo that the user is forced to think about what he is doing when 
he writes it down, 

3- As PLANNER is cutrantly organized* the easiest program to 
write in HANKIE is an exponential depth-first search, Other program 
organisations, though certainly possible in PLANNEE, are clearly more 
complex. This is because PLANNER is trying to be both general slid 
automatic. The defaults are chosen throughout the system so that 
backtracking happens unless you explicitly prevent it from happening. It 
is easy to say that people should write their programs to avoid 
backtracking except when absolutely necessary, but It is much harder to 
actually do it when the language gives you every opportunity to write bad 
programs. 

4. In order to give the user a modicum of control over the 
dangerously uncontrolled backtrack me chard sm, ihdlure messages were 
incorporated. The basic idea of failure messages is that the user should 
be able to program in the ability to fail to a specific point which he 
sets up tc catch the failure by matching its message. This does not give 
the user the ability to perform even the simplest of control functions. 
Suppose, for example, we have a goal Which invokes a theorem. This 
theorem, in probing the search space, discovers structure in the space. 

It would like to get at the list of theorems which are pending in the 
goal which called it (the alternatives which will be tried if the current 
theorem falls) and edit it. It would perhaps like to filter it, deleting 
some entries and Inserting others. It might even wish to sort the list 
of alternatives according to some general criterion. It has not yet. 
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however, failed,, and thus cannot return a failure message* further more, 
it cannot get at the list of alternatives pending on its failure. This 
is not a minor problem; it comes up in Greenblatt's chess program very 
often. Tor example, an analysis of a move may discover that we are in 
danger of being forked. This chants the whole set of criteria ly which 
we want to judge alternatives. We must try to make a move which meets 
the discovered threat, if possible. 
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CGimi VER — A Different Approach 

J'or some time I have been studying FLANKER and the uses to which 
it has been put* hoping to learn yust what modifications would he 
desirable to the user dorjounity* As we have seen, these investigations 
have led me to decide that the basic structure of PLANNER, was- wrong, 
though its manifest success indicated that it contained many good and 
powerful ideas* This observation, that we were faced with a structure of 
good ideas glued together haphazardly with the poor glue of automatic 
backtracking, led to the design of a now language, OGNNXYU?, which 
incorporates those good ideas in a cleaner structure. OQNlillVER is 

designed to satisfy the following desiderata: It must be automatic 
enough to be easy to use without being so automatic as to relieve the 
user of the responsibility for the behavior of his program. Thus, it 
must provide the user with the equipment to use powerful tools like 
backtracking and multi processing, relieving him of the low level 
bookkeeping needed to implement such mechanisms, without automating the 
invocation of these massive mechanisms,. COHNlVffl must walk this 
tightrope while maintaining simplicity by keeping the number and 
complexity of the primitives small* This path has been abandoned by 
PLANNER which started out as a simple and elegant (but not necessarily 
right) theory of problem solving, but which recently, in its effort to 
become ar, all inclusive panacea, gobbled up every idea ever proposed for 
the implementation of algorithms, regardless of considerations of either 
merit of the ides or consistency and parsimony of the theory- The last 
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major consideration is that there must be no invisible control structure* 
such as the Implicit loops with undefined scopes that were objected to in 
the last section. In COHNIVER the user is forced, often to his 
inconvenience, to explicitly outline his control structure, keeping him 
honest and Ms program clear. With this in mind I now proceed with a 
description of COMJfIVER. 

Ue first consider that pert of CQNNIVfli which introduces no 

control structure more exotic than recursion. Hus is done mainly to 
show just how much of the "normal" programming people do in FLANKEft via 
backtracking (the "natural" method in PLANNER) can be done more- clearly, 
easily, and efficiently via the more conventional structures of recursion 
and iteration* he assume that CONNIVEK lias available to it a PLANNER- 
esque pattern matcher and is embedded, as is PLANNER, in a LISF^like 
language (such as MUDDLE)* litis section will deal primarily with the 
information retrieval aspect of the kind of programming people do in 
FLANKER, including the construction arid maintenance of a pattern—directed 

data base and the use of pattern-invoked procedures. This, I have 
observed, campriees the largest proportion of legitimate MICRO-PLANNER 

programming. 

In Cider to- avoid confusion Wi th PLANNER, similar constructs in 
CONNIVES will be given different names from those used in PLANNER. The 
objects in the data base which correspond to assertions in PLANNER will 
be called items , pattern^ invoked functions, which correspond to theorems. 
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will be called methods and. also appear in the data base. In OOWniVEf: the 
data base is a tree structure of contexts and all additions* deletions, 
and searches are done relative to sc-ne context, just as variable bindings 
are searched and set relative to an environment in LISP,. As we shall see 
later* variable bindings and flow of control in OOHKIVER are also context 
dependent* Tor now, however* we need only know that the context is 
poshed (bound) at some functional (or methodological — ha!} invocations 
and popped (unbound) at some returns. As in LISP, every time we do a 
bind ve obtain an environment which contains the previous environment, so 
in CONNIVEB, each tiite we rebind the context* we obtain a new context 
which contains the previous context as a subset. It is important that 
the direction of containment be understood as it is critical and contrary 
to the direction of lexical scoping. 

The data base- construction primitives are as followsi ( Syntact ic 

variables are lov^r case* optional arguments are delimited by dashes t 
segment syntactic variables are delimited by stars, and procedural 
invocations ly angle brackets..) 

1) <AfiD item skeleton or method -context-)* 

2) <DEUE3!E item skeleton or method “Context-> 

These add (or delete) the item or method indicated to the context 
indicated. If no context is given, the current one is assumed. Objects 
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in a context are accessible to all containing contexts. If' the object to 
be added (or deleted) is already accessible (or inaccessible) in the 
context given ALP (DELETE) has no effect. Often, rather than actually 
deleting an object from a subcontext of a given context one really would 
rather hide it from all contexts containing the given context so that it 
will reappear when the given context is flopped. Thus we have: 

3) <EID£ item skeleton or method —context-> 

4) <REVRAL item skeleton or method ~context-> 

REVEAL undoes a RIDE just as a DELE TE undoes an ADD. Corresponding to 
the antecedent and erasing theorems in PLANNER, CGHNIVER has context 
monitoring methods which monitor all Contexts which contain them (except 
contexts from which they are hidden). The various monitor methods are: 

5) <11—ADDED declaration pattern *bcdy*> 

6) sli'-LELRTED declaration pattern *body*> 

If an itea is added (or deleted) to a context the context is searched for 
monitors whose pattern matches the item affected and all such monitors 
are run in the order they are found. These monitors arc not to be 
Confused with the daemons which watch subcontexts from supercontexts and 
are described in the section on fancy control structures- 
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Wow that we have our data Mae built up, how do we use it? 
CQKNIVER has one basic primitive for accessing the data base: 

7) <]' 1 Fl'CH pattern -context-> 

I ETCH searches the context indicated (if none is given the current one is 
assumed) for items and If-NEEDED methods (analogous to consequent 
theorems) matching the pattern given* It returns a list of 
pc ssi bilit ies > the for Bat of which will be discussed, hut which logically 
consists of the items found followed by the net hods applicable in the 
context* The user may, for example, examine the list, sort it according 
to some criteria, or edit it as he chooses. The main way ho will use 
this list, however, is as follows: 

£.) <TRI-KEXT list of possibilities no more return filter > 

Executing, this primitive causes the following: If there arc any 
possibilities, the first one is "tried w and removed from the list* If 
there are none left, the expression passed in no more is evaluated. Kow 
what do 1 mean by tried? Now I must describe the format of the list. 
Suppose the current context has items: 


(SUSSHAN IS—A CROCK), and (MOSES IS-A, 10SER) 
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and we execute; <FETGH (?X is-A 77)? 

It will return as a value the list: (((X SUSSMAU) {1 CROCK)) ((X MQGES) 
<Y LOSER))), 

That is* each possibility is a possible set of assign merits for the 
variables in the pattern- Trying the first of these means setting X to 
ELTSSt-iAJf and Y to CROCK* These are iteji po ssib ill ties » Suppose one has 
exhausted the item possibilities and that the next possibility is a 
i.ethodclogical possibility * The indicated method is executed* The value 
it returns to the TRY-UEXT is then interpreted as a set of item 
possibilities with which it is to be replaced. These, after be ins 
examined by the return filter, are then appended to the beginning of the 
list and the first one is tried. If none are returned, the first one is, 
of course, the next method* A method may thus return as a suggested 
possibility another method, not necessarily applicable in this context, 
thus providing a powerful mechanism for recommendations- bet us now locfc 
at an. IF-NEEDED method: 

9) <IF—IvEEHED declaration pattern *tody*> 

As such a method rubs, every so often it decides that the current 
assignments to the variables in the pattern are valuable and should be 
noted, to do this we execute: 
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10) <frOTE -variable-> 

If no variable is specified the note is made by addins the current 
substitution instance of the Method pattern to a list stored, in the value 
of the variable PROPOSALS, which is automatically bound on entering an 
IF—WEEDED* If a variable is specified, it is the receptor of the noted 
proposal* The proposals are returned by: 

11) <ADIEU -list of proposals—> 

ADIEU returns the list of proposals. If no such list is given, it 
returns from the oethod with the value of PROPOSAL. Similarly, if a 
method runs off its end, it returns the value of PROPOSALS* 

By now you are probably complaining H 5o what, it looks like 
ELAWWE6 to me, with the mm.es changed and the data base slightly 
hairier**' ifote, however, that I have made no mention of any fancy exotic 
control structurej there is not yet any backtracking or failure (the same 
thing) or multiprocessing* These structures have their place in 
CGMXVER, as we shall see, but almost all of the program currently 
written in MlCRfr-PLAWNEft can be written in the given subset of OOMNIVEH 
with only a net incYea&e in clarity, efficiency, and without 
backtracking, 1 will illustrate this soon with examples, but first let 
me summarize that this recursive subset of CCMIVER is just the PDAiiWEJi 
data base searcher, pattern matcher, and. pattern directed procedure 
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invoker lifted from the encumbrance of all—pervasive backtracking and 
placed on its own to be used separately. 

We shall now do the infamous (HUMAN HIRING) example — often used 
to demonstrate backtracking, 10r convenience, before we start I wish to 
define a macro which packages a common loop- I want to make it clear 
that I do not coutdone the general use of TOR-EACH; it is just OCMHIVER's 
way of simulative PLANNER*s GOAL for illustration. It will not be 
provided as a primitive of the system, as it is too easy to use 
carelessly for searching without direction. In the following let <FGH- 
EACH pattern *body*> expand into: 


<rEPEAT ((POSSIBILITIES <FETCH pattern^)} 
<TRY-NEKT* POSSIBILITIES <RETUKB ()» 
*body*> 


We are using Ml/LiELE syntax. Note that when we run Out of possibilities 

we just have the loop terminate by recursive return? there is no PAIL, 
We now compare OCNNIVER with PLANNER, We first ask for & fallible 

object; 


<H£QG (X) ' 

<FGR-EACH {TALLIELE ?X) 
<RETURN -X»> 


<PRQC (X) 


<GOAL (F ALLIBLE <’X)> 
<RETURM ,X>> 
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So far, there is no difference; now ve need the method (.theorem) "humans 
are iamble". 


<IE-A'EEEED (X) (PAIUELE ?X) <CCHSEQUEHT (X) (FALLIBLE ?X) 

<IOR-EACH {HUMAN ?X) <HOIB>» <GOAL (HUMAH ?X)» 

Again, no real difference* It comes* however, when we "need 11 
backtracking to further restrict the answer to Creeks; 


<PftDG (X) 

<POR-EACH (FALLIBLE ?X) 
<K£v-EACH (GREEK ?X) 


<PROG (X) 

<GGAL (FALLIBLE ?X)> 
<GOAL (GREEK ?X)> 


<RETURN ,X»» 


<RsrURX ,x» 


Our first observation should be that we didn't really need backtracking 
since CONXIVER cane up with the answer without backtracking or other 
control structure kludgery! I furthermore wish to argue that the 
COftklVER answer is clearer than the PLANNER answer* Ky reasoning is that 
in the PLANNER case one must think about the implicit loop (find a 
fallible X, is he Greek? if not get the next one. If so return) in 
order to really understand the program- That loop, however, is not 
properly nested; its scope is not clear since you can fall back into it 
from the return below it* This form of badly nested loop, which is the 
ballpark of PLANNER'S form of backtracking, is a very powerful but 
dangerous feature. Any such feature which disrupts the local control 
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structure of a program (such as jumping into the scope of a IX) loop) 
should be avoided like the plague* because of the resulting lack of 
clarity and nodularity of code, unless Its absence poses a serious 
hardship. As will be discussed in the next section, COIfNiVU? supplies* 
for the cases where it is needed, a very different form of backtracking 
whose presence is much less disruptive t and which easily replaces PLAHKER 
type backtracking in those eases where it is justified. 
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HAIRY CONTROL STRUCTURES 
the Truth about CGNNIVER 


By now you should be raising the serious question "What was that 
magic in the last section? how is Sussiaan cheating? Where has he paid 
for his heresy?" One possible objection to what I did is that I censed 
up a giant list of possibilities (or proposals) which I had to carry 
around with me- that objection, however, is invalid. If you have a 
program which has huge numbers of possibilities at each turn* your 
chances of getting a PLAINER program or a CONN TVER program to terminate 
before the sun blows up are equally infinitesmal* In either case, you 
had lietter come up with a better theory of the problem which narrows the 
search space to a more manageable proportion- Furthermore, what COKNIVEFi 
cunses up as a list, PLANNER pushes on the stack since all untried 
possibilities Bust be eventually tackled. Then what is backtracking 
really about? Is there a case where backtracking: is really relevant? 

The answer is yes - Consider the fact that whenever TRY-NEXT invokes a 
method, the poor method must come up with a proposal and then soy "does 
this satisfy you?" expecting to work very hard to get the next one if 
the answer is no- Thus if there are only a few proposals but coming up 
with one is much harder than trying it out, we have a real need for 
1 jack tracking, OONMV'ER does, in fact, give you this feature if you 
really need it, but you must carefully think about it before you use it* 
The great disadvantage of backtracking is that the possibilities cotae 
only one at a time, thus we have no list to sort and filter and thus we 
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find it harder to bring knowledge of the problem space to bear on the 
solution* CQliKIVEE provides the following backtracking primitive; 

12) -CAIWtEVCdR -variable^ 

AU-EEVOUi, like ADIEU, causes a method to return to the TRY-ilEXT which 
invoked it with a list of proposals, either the value of the variable 
specified, or the value of FftOFGGAl& if none is specified, The 
difference is that AU—REVOItt specifics fcljat if the proposals returned are 
exhausted and you still need more, the method which called AIH3EVGIR will 
be resuaed in the context it returned from as if AU-REVQIR had returned 
to it. The value of AU-EEVOIR is a failure nessage which car be set by 
the user as the value of an optional fourth argument to TRY-hEXT, The 
user can then try to figure out how to use the message in the method 
failed back to. The example method of the last section can be written 
using backtracking as follows; no modifications are necessary to the 
caller: 


<JF-hEEDED (X) (FALLIBLE ?X) 

<FOR-EACH (HUMAJC ?X) 

<HQTE> 

' <AU-f^EV01fi»> 

hote that backtracking in CQHHIVER hardly interferes with the proper 
nesting cf the (propose a goodie — try it out) loop structure of either 
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the method or of the caller {unmodified). In contrast with HANTS PR's 
fchronolcgi cal backtracking , the recursive backtracking of GGMIVIR does 

not disrupt a program's recursive structure- Wot Only does this lead to 
benefits of clarity, legibility t and ease of debugging, (as well as ease 
of implementation}., it also neans that failure messages are much sore 
useable in COMIVER than in PLAUWER because the guy who is rejecting a 
goodie sent to him complains directly to the guy who sent it, not one of 
his henchmen who hangs later down the backtrack stack* 

You must realise, of course, that what is meant by backtracking 
in CGWWIYEE is not the sane is whet is meant by backtracking in PLAWEFi. 
koto that in backtracking to an AU—RLVGIE no decision has been unmade. 

In general, CGXNIVER backtracking does not mean undoing something which 
has been done. Wo items are ever removed from the data base except by an 
explicit call to DELETE or by popping the context in which the item 
resided by re turning from it in the standard recursive way. The 
distinction becomes clearer if we consider the way one would handle a 
choice point in each language. In PIAMNEJi you choose one of the possible 
choices and proceed, deducing the consequences of the choice made until 
either the program terminates, indicating that the choice was a correct 
one, or a failure occurs, undoing the deduced consequences until the 
choice point is reached, where a different decision is made* In 
COKNIVERj on the other hand, Choices are made by calling one of several 
possible subroutines- A new context is then set up in which the 
consequences of the choice are stored. In any case, success or failure 
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of the choice is indicated hy the return of the function call which made 
the choice, unbinding the context of the choice* It in then up to the 
calling program to decide hoy to proceed. This decision may be made on 
the basis of examining the value returned by the subroutine and whatever 
changes it made to the more global data base and variable bindings* In 
this scheme a choice does not just succeed or fail. It very naturally 
tids the power to probe the structure of the problem domain* adding 
Whatever it learns to the contexts of its calling procedures, thus 
modify! nr their behavior* 

In CCSTOJIVER, therefore, what 1 called backtracking is really just 
a method of saving the current context (of the AU-REVOXR as the last 

proposal returned) sc that it is not lest when popped (it is saved in 
POSSIBILITIES) and can be re-entered and continued where it left off (by 

ThY-KEXT, when it hits this new third kind of possibility, a context). 
Ihis is really a very general form of mulitprooessing control* Itor such 
a control structure to be possible* the underlying applicative language 
must have (logically) a list structured control stack. 

leeides giving us this different form of backtracking* COMIYER 
also provides us with daemons * Int what is a daemon? liaemon is one of 
those nice words that everybody "knows 11 the meaning. of t until they try to 
formalize it- Perhaps first an example is in order* Many times, when 
attacking a problem in mathematics the first approach taken fails because 
of & specific unsolved subproblem* Another approach is then tried which. 
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In itself, does not solve the problem, but which discovers information 
which unblocks the first approach (an impossible situation if it really 
failed in the PLANNER sense) which then proceeds to solve the problem* 

Ira Goldstein has given me a specific instance of this in geometry. In 
his case, the first approach to a proof, (and also the eventual uimerJ 
which was chosen first because of its extreme plausibility, becomes hung 
up on a subproblem that depends upon a very implausible construction. 

The second approach then finds the construction required extremely 
plausible and does it* The consequences of this construction should then 
wake up the first approach. COMNIVEfc provides the following primitives 
to implement these ideas: 

13) <HANG release condition context> 

If flAHG is executed, the program ceases execution in the current context. 
Control is passed to the context given* If the release condition is ever 
satisfied by any computation, the running context Is stopped and control 
reverts to the HANG which then returns as its value the interrupted 
context* Some possible release conditions are: 

a} <ALD pattern -centex t-> 

b) <L£LETE pattern -contexts 

c) -CKXT'hRWAL-COhlITI OH type> where type might be CLOCK-TICK, 


TTY, etc, 

d) <I!fnRNAIj-CONDITION type> where type might be: FLOATING- 




OVE&ELQW, etc* 

e) hEVER - means only if explicitly resuaetf* 

The current context can always be gotten as the value of 


14) <COUTEXT> 


